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Abstract 

In  a  1998  C2RT  Symposium  paper  [Chamberlain  1998],  the  thesis  was  presented  that  the  concept 
of  organization  (or  task  organization)  is  the  central  theme  by  which  all  battle  command 
representations  revolve.  In  essence,  the  organizational  structure  forms  a  skeleton  to  which  all 
other  battlefield  entities  can  be  related,  making  the  organization  data  structures  the  rallying  point 
for  the  integration  of  other  databases,  such  as  logistics,  personnel,  and  communications. 
However,  one  of  the  hypotheses  presented  states  that  fluid  Orders  Of  Battle  (OOB)  can  most 
always  be  built  by  re-linking  existing  organizations  from  a  stable  default  organizational  structure. 
But  for  this  to  be  effective,  the  default  structure  must  include  more  nodes  than  are  present  in 
current  default  structures.  This  paper  introduces  Default  Operational  Organizations  (DOO)  that 
are  representations  of  military  organizations  that  meet  the  requirements  necessary  to  build 
arbitrary  OOBs  across  joint  Services.  By  looking  closely  at  how  each  service  organizes  for 
combat,  basic  tenets  were  developed  in  an  attempt  to  reduce  many  practices  to  a  few  fundamental 
concepts.  The  result  is  a  set  of  guidelines  based  upon  the  “best  practices”  of  all  the  services. 

1.  The  Organization  Server  Architecture 

Currently,  there  are  numerous  approaches  for  identifying  organizations  and  this  is  hindering  the 
ultimate  goal:  the  ability  to  “plug-and-play”  task  organizations  across  international  and  Service 
boundaries  while  building  Military  Capability  Packages  (MCP).  The  purpose  of  an  organization 
server  is  to  provide  organizational  information,  in  a  homogeneous  structure,  about  military  forces 
down  to  the  individual  billet  level.* 1  This  also  requires  that  a  universal  way  to  identify 
organizations  be  defined.  A  proposed  solution  is  to  use  a  simple  numbering  scheme — in  this  case, 
a  32-bit  integer  called  an  organization  identifier  (ORG-ID) — that  is  capable  of  covering 
approximately  4.3  billion  organizations  if  none  is  wasted.2  This  approach  can  also  be  applied 
across  Services,  non-govemment  organizations,  and  countries.  To  prevent  waste,  ORG-IDs  are 
not  assigned  by  blocks,  but  instead  on  a  first-come,  first-served  basis  from  an  Org-ID  server. 
Thus,  implementation  is  via  a  two-tier  hierarchy  of  servers:  (1)  a  set  of  Org-ID  servers  that  pass 
out  unique  Org-IDs,  and  (2)  organization  servers  (org  servers)  that  maintain  the  actual 


*  This  research  has  been  sponsored  in  part  by  the  DOD  Command  and  Control  Research  Program  under  the  ASD(C3I). 

1  Dictionary  of  Military  Terms  -  http://www.dtic.mi1/doctrine/iel/doddict/data/b/00866.html 

Billet:  A  personnel  position  or  assignment  which  may  be  filled  by  one  person 

2  4.3  billion  numbers  are  enough  to  uniquely  identify  every  node  in  approximately  213,000  U.S.  Army  Divisions. 
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assignment  of  Org-IDs  to  organizations  while  maintaining  the  organizational  data;  this  is 
illustrated  in  Figure  1 . 


The  separation  of  Org-ID  servers  from  org  servers  is  significant  because  it  allows  selective 
sharing  of  order  of  battle  (OOB)  information  while  participating  in  the  open,  Org-ID  assignment 
system.  It  is  hoped  that  this  will  encourage  participation  by  those  who  would  not  otherwise  do  so 
for  security  or  sovereignty  reasons.  The  jurisdiction  of  org  servers  is  completely  flexible.  For 
example,  within  the  United  States,  there  could  be  org  servers  for  each  Department  of  Defense 
(DOD)  service,  the  Office  of  the  Secretary  of  Defense  (OSD),  other  Government  organizations 
(e.g.,  State  Department),  non-govemment  organizations,  and  private  volunteer  organizations. 
Each  org  server  controls  the  dissemination  of  its  information;  however,  it  is  expected  that  the 
DOD  members  would  normally  share  information  with  each  other  (within  the  usual  security 
limitations). 

When  an  authorized  user  wants  to  create  a  new  organization,  an  Org-ID  (or  set  of  Org-IDs)  must 
be  obtained.  To  do  this,  a  request  is  sent  to  one  of  several  Org-ID  servers.  The  Org-ID  servers 
authenticate  the  request  and  provide  guaranteed  unique  integers  to  the  requester — that  is,  they 
ensure  that  the  integers  they  provide  have  not  been  given  to  any  other  authorized  user.  The  Org- 
ID  server  associates  each  Org-ID  with  the  org  server  to  which  it  was  delivered,  marks  the  Org-ID 
as  unavailable,  and,  initially,  sets  the  Org-ID’s  status  as  dormant.  At  a  later  time,  probably  within 
some  previously  agreed  upon  limit,  when  the  org  server  assigns  its  Org-IDs  to  real  organizations, 


it  must  notify  the  Org-ID  server  that  the  Org-IDs  are  now  in  service.  An  org  server  may 
inactivate  an  Org-ID  at  any  time,  reuse  it  at  it  pleases,  or  even  return  it  to  the  Org-ID  server  for 
reuse.  The  Org-ID  server  has  little  control  over  an  Org-ID  once  it  is  delivered  to  an  org  server. 

2.  A  Simple  Data  Abstraction  for  Organizational  Structure 

Ultimately,  organizations  manifest  themselves  as  organization  charts.  To  formalize  the  process  of 
building  these  charts,  they  are  considered  in  terms  of  graph  theory.  A  graph  is  composed  of 
nodes  and  links  (i.e.,  vertices  and  edges).  A  tree  is  a  special  graph  that  is  fully  connected  (i.e., 
every  node  is  linked  to  at  least  one  other  node)  and  there  are  no  cycles  (i.e.,  only  one  path  exists 
between  any  two  nodes).  Figure  2  summarizes  a  few  graph  theory  terms. 


Parent 


NODES  (or  vertices ):  A,  B,  C,  and  D 
LINKS  (edges):  [A,B],  [A,C],  and  [A,D] 

A  Tree  structure  is  a  “connected”  graph  with  no  “cycles,” 
i.e.,  only  one  path  exists  between  any  two  nodes. 

A  node  can  be  a  parent  and/or  a  child  of  another  node. 

A  node  with  no  parent  is  called  a  root  node  (e.g.,  A). 

A  node  without  a  child  is  called  a  leaf  node 

(e.g.,  the  nodes  at  the  bottom  of  the  tree:  B,C,  and  D). 


Organization  Charts  are  Trees  (w/  boxes  instead  of  circles): 

[Al  [A]  m 

-m 

-GD 


[b]  [c]  GO 


Figure  2:  Graph  Definitions  and  Terms 


By  definition,  nodes  (e.g.,  A,  B,  C,  and  D  in  Figure  2)  represent  organizations  and  hnks  ([A,B], 
[A,C],  and  [A,D]  in  Figure  2)  represent  chains  of  commands.  Each  organization  (or  node) 
receives  an  Org-ID,  thus  allowing  chains  of  commands  to  be  explicitly  defined  via  parent-child 
relationships  between  organizations.  For  example,  a  link  between  A  and  B  may  be  formally 
defined  via  the  relationship  assigned[A,B],  where  “assigned”  is  the  relationship  type,  A  is  the 
parent  node,  and  B  is  the  child  node.  One  of  the  goals  of  this  project  is  to  produce  unambiguous 
organization  charts,  which  means  defining  unambiguous  chains  of  command.  In  other  words, 
there  may  be  more  than  one  chain  of  command  at  one  time  (e.g.,  one  for  administration  and  one 
for  operations),  but  a  given  chain  of  command  must  be  explicit,  unambiguous,  and  have  tree 
properties.  Further,  one  must  decide  what  constitutes  a  bona  fide  organization  and  what  the  links, 
or  relationships,  between  them  formally  represent  (e.g.,  what  does  the  relationship  “assigned” 
mean).  This  doesn't  mean  that  every  system  has  to  display  organization  charts  the  same  way,  but 
only  that  the  organizational  structure  should  be  represented  inside  the  computer  using  a  common 
set  of  semantics.  If  this  is  done,  one  can  begin  to  build  “plug-and-play”  task  organization 
applications  that  extend  across  the  services,  and  even  coalitions. 


If  one  asks  10  different  people  to  “draw  an  organization  chart”  of  their  organization,  one  will 
often  receive  10  different  structures.  This  characteristic  is  indicative  of  the  informal,  human- 


oriented  nature  of  our  battle  command  processing.  Unfortunately,  computers  aren’t  clever 
enough  to  figure  out  what  all  these  relationships  infer.  Consequently,  one  needs  to  formally 
describe  the  “age-old”  chain-of-command  relationships  terms  that  are  routinely  used  and  have 
numerous  inferred  meanings  and  ramifications.  This  paper  describes  several  basic  tenets  for 
defining  this  structure  in  a  format  conducive  to  machine  manipulation. 

3.  Default  Operational  Organizations 

One  reason  for  setting  up  the  org  server  system  is  to  simplify,  enhance,  and  formalize  the  task 
organization  process  within/between  U.S.  services  and  between  coalition  partners.  One 
hypothesis  presented  in  Chamberlain[1998]  is  that  fluid  OOBs  can  most  always  be  built  by  re¬ 
linking  existing  organizations  from  a  stable  default  organizational  structure.  But  for  this  to  be 
true,  the  default  structure  must  include  more  nodes  than  are  present  in  current  default  structures. 
Just  entering  current  manning  documents  into  the  org  servers  (org  servers)  will  not  accomplish 
the  desired  capability  because  many  important  low-echelon  organizations  are  inferred  or  are 
missing.3  Therefore,  these  organizations  must  be  explicitly  added  to  allow  the  org  server  system 
to  meet  its  potential. 

The  term  Default  Operational  Organization ,  abbreviated  DOO,  is  introduced  as  the  name  for  the 
enhanced  organizational  structure  that  is  maintained  in  the  org  servers.  The  DOO  is  the 
conceptual  “stable,”  generic  organization  that  represents  the  “relaxed”  state  of  the  force  before  it 
is  task  organized.  It  begins  at  some  arbitrary  high  echelon  (e.g.,  DOD)  and  continues  all  the  way 
down  to  the  individual  warriors.  A  DOO  is  constructed  by  two  tasks.  First,  the  current 
administrative  organization  represented  by  standard  manning  documents  is  translated  into  “nodes” 
and  “links”  (i.e.,  organizations  and  a  default  chain  of  command).  This  may  require  some  basic 
modifications  to  remove  circular,  duplicative,  and  ambiguous  links  that  can  cause  logic  problems 
and  prevent  the  graph  from  being  a  tree.  Second,  three  other  types  of  organizations  are  added  to 
fill  in  the  many  gaps  left  after  translating  the  manning  documents.  These  types  are:  billets 
(organizations  that  have  a  one-to-one  correspondence  with  a  person),  crews  (or  organizations  that 
are  created  for  the  purpose  of  operating  a  piece  of  equipment),  and  doctrinal  organizations 
(based  upon  operational  fighting  doctrine  or  heuristics).  The  next  part  of  the  paper  discusses 
these  “interesting  cases”  and  anomalies  discovered  during  their  definition. 

3.1  Billets  and  Commanders 

Approximately  80%  of  the  organizations  in  a  force  reside  in  the  “leaf  nodes”  of  the  organizational 
hierarchy  that  correspond  to  individual  people — officially  called  billets.  Current  operational 
military  organization  databases  extend  down  to  the  “Company  Level”  in  the  Army  and  Marine 
Corps.  A  Unit  Identification  Code  (UIC)  that  is  used  for  strategic  planning  purposes  is  assigned 
down  to  this  echelon.  However,  UICs  were  established  for  logistical  reasons,  not  for  command 
and  control.  The  company  level  was  chosen  as  the  lowest  echelon  because  it  is  where  supplies  are 
delivered.  It  is  important  to  realize  that  this  is  an  arbitrary  stopping  point  in  the  process  of 
defining  organizations.  If  one  continues  expanding  an  organization  chart,  eventually  one  will 


3  Manning  documents  include  Army  Tables  of  Organization  &  Equipment  (TO&E),  Air  Force  Unit  Manning 
Documents  (UMD),  Navy  Ship  Manning  Documents  (SMD),  and  Marine  Corps  Tables  of  Organization/ 
Equipment  (TO/TE). 


produce  organizations  that  have  a  one-to-one  correspondence  with  a  person.  This  echelon  is 
called  a  “billet”  in  the  official  DOD  dictionary  and  is  illustrated  in  Figure  3. 

In  the  general  case,  billets  correspond  to  “warrior”  positions.  These  are  the  personnel  positions 
that  are  occupied  by  soldiers,  sailors,  airman,  and  marines  doing  the  many  tasks  required  of  a 
military  force.  People  are  ultimately  assigned  to  billets,  but  this  does  not  change  the  fact  that 
billets  are  just  another  organization.  However,  the  association  between  a  person  and  a  billet  is 
technically  different  than  the  association  between  two  organizations.  There  are  many  different 
types  of  associations,  henceforth  referred  to  as  relationships.  To  differentiate  between  the  two 
categories,  they  will  be  called  organization-to-organization  relationships  (OTOR)  and  personnel- 
to- organization  relationships  (PTOR).  In  Figure  3,  the  links  between  organizations  (such  as  A 
and  B,  or  B  and  F)  are  OTORs,  while  the  arrows  between  people  and  organizations  (such  as  U  to 
D,  or  Z  to  I)  are  PTORs.  Many  OTORs  already  exist  with  names  such  as  assigned,  attached, 
operational  control,  and  direct  support.  PTORs  are  less  formally  defined.  Both  the  number  and 
description  of  OTORs  and  PTORs  will  have  to  be  enhanced  to  formally  cover  the  many  cases  that 
occur  in  real  life.  One  example  may  be  a  PTOR  for  acting  roles  to  indicate  that  a  person  both 
occupies  one  billet  but  is  also  temporarily  serving  in  the  capacity  of  another.  This  is  common 
when  a  commander  goes  on  leave  and  another  officer  is  “put  in  charge”  during  the  absence. 
Another  interesting  situation  is  that  it  is  not  unusually  at  the  upper  echelons  (e.g.,  for  flag  officers) 
to  be  assigned  to  several  billets  at  one  time.  This  is  referred  to  as  “wearing  several  hats.”  For 
example,  the  person  filling  the  billet  of  Commander,  U.S.  Forces  Korea  (USFK),  also  fills  the 
billet  of  Commander,  United  Nations  Command  (UNC),  and  Commander,  Republic  of  Korea- 
U.S.  Combined  Forces  Command  (CFC). 

A  special  case  is  “command  billets.”  It  is  important  to  be  able  to  ascertain  who  is  the  commander 
of  an  organization.  However,  command  billets  are  often  nested  several  layers  down  from  the 
organization  that  is  actually  commanded.  For  example,  the  command  billet  for  an  Army  Division 
is  a  sub-element  of  a  “Command  Section,”  that  is  a  sub-element  of  a  “Headquarters  and 


Figure  3:  Billets  Ultimately  Form  the  Leaves  of  the  Trees 


Headquarters  Company"  (HHC),  that  is  a  sub-element  of  the  organization  called  a  “Division.” 
This  hierarchy  is  illustrated  in  Figure  4.  This  relationship  is  relatively  easy  to  understand  with 
some  military  experience  coupled  with  an  organization  chart  that  includes  echelon  symbols  and 
organization  names  as  in  Figure  4. 

However,  a  more  formal  description  is  required  for  computers  that  must  deal  with  an  abstract 
chart  such  as  that  shown  in  Figure  5.  To  fix  this  problem,  a  new  OTOR  called  is-commander-of, 
which  links  a  command  billet  with  the  organization  for  which  it  has  command,  is  introduced.  This 
is  illustrated  in  Figure  5  between  nodes  F  and  A  and  between  nodes  H  and  B  (note:  Figure  5  is  the 
abstract  case  of  the  example  shown  in  Figure  4).  Because  a  PTOR  exists  to  assign  person  X  to 
organization  F  (a  command  billet),  it  is  easy  to  determine  that  person  X  is  in  command  of 
organization  A  (e.g.,  MG  Jones  is  in  command  of  the  32d  Division  in  Figure  4).  In  formal  terms, 
is-assigned-to(X,  F)  AND  is  -  commander- of (F, A)  implies  is-commanded-byi  X ,  A ) ,  which  is  a 
derived  PTOR.  Thus,  no  matter  where  a  command  billet  is  placed,  one  can  easily  ascertain  who  is 
in  charge  of  what. 


Figure  4  and  Figure  5  still  have  a  significant  problem.  Because  Army  TO&Es  are  logistic  based, 

Figure  4:  Nested  Command  Billets  Figure  5:  Abstract  View  of  Nested  Command  Billets 

the  tree  structure  focuses  on  logistic  responsibility  rather  than  the  chain  of  command.  Notice  that 
there  are  two  command  billets  under  one  node  (i.e.,  nodes  F  and  H  under  B,  which,  in-tum,  is 
under  A).  This  produces  an  ambiguity  when  rules  of  transitive  closure  for  trees  are  followed.4 
Typically,  if  A  is  in  command  of  B,  and  B  is  in  command  of  C,  then  A  is  ultimately  in  command  of 
C.  But  there  is  a  contradiction  in  Figure  5: 

B  is-a-child-of  A  AND  H  is-a-descendent-of  B; 

Since  F  is-commander-of  A  AND  X  is-assigned-to  F  AND  Y  is-assigned-to  H, 

THEN  Person  Y  must  be  ultimately  commanded  by  Person  X. 

However,  if  one  looks  at  the  tree  rooted  at  node  B,  there  is  a  different  conclusion: 


4 


Transitive  closure  states  that  IF  A=B  AND  B=C,  THEN  A=C.  Likewise,  the  *=’  relationship  may  be  replaced  by 
some  other  relationships:  IF  A  is-an-ancestor-of  B  AND  B  is-an-ancestor-of  C,  THEN  A  is-an-ancestor-of  C. 


Like  H,  F  is-a-descendent-of  B; 

Since  H  is-commander-ofB  AND  Y  is-assigned-to  H  AND  X  is-assigned-to  F, 

THEN  Person  X  must  ultimately  be  commanded  by  Person  Y. 

Both  of  these  statements  cannot  be  true.  A  conclusion  should  not  depend  on  which  node  one 
begins  the  process.  This  problem  is  caused  by  a  cycle  in  the  graph  that  is  a  result  of  the  Division 
Command  Section  being  placed,  for  logistics  reasons,  under  an  HHC  that  also  has  its  own 
commander.  This  practice  occurs  at  all  level  above  the  company  echelon  (where  HHCs  exist) 
because  the  subordinate  organization  (the  HHC)  has  responsibility  for  the  commander's 
equipment.  Thus,  the  practice  of  building  “official  organizations  charts”  based  on  logistic,  rather 
than  chain-of-command,  considerations  can  cause  command  ambiguities  if  not  treated  correctly. 


To  fix  this  problem,  “command  groups”  must  be  pulled  out  from  under  subordinate  commanders 
to  prevent  circular  command  chains.  This  revives  the  “tree  property”  of  the  organization  chart 
and  provides  a  clean  chain  of  command  structure  as  is  illustrated  in  Figure  6.  A  new  OTOR 
called  “has  logistics  responsibility  for”  can  be  added  to  formalize  the  fact  that  the  HHC  still  has 
responsibility  for  the  equipment  of  the  command  group. 


Figure  6:  Non  nested  Chain  of  Command 

3.2  Crews 


A  common  practice  is  to  create  an  organization,  commonly  called  a  crew,  for  the  purpose  of 
operating  a  specific  piece  of  equipment.  Crew  sizes  vary  widely  from  a  single  person,  such  as  a 
fighter  pilot,  to  thousands  of  people,  such  as  a  ship’s  crew,  organized  into  many  sub¬ 
organizations.  The  purpose  of  this  study  is  to  attempt  to  identify  common,  general  traits,  and 
practices  that  can  be  applied  to  the  organization  data  abstraction  process  regardless  of  crew  size 
or  the  equipment  operated. 


Of  particular  interest  is  the  manner  in  which  one  associates  a  crew  with  its  equipment.  For  this 
discussion,  the  term  “asset”  is  used  interchangeably  with  equipment  because  it  more  generally 
characterizes  the  problem.  By  definition,  the  process  of  associating  an  asset  to  an  organization  is 
coined  alignment.  Therefore,  to  describe  alignments,  a  new  category  of  relationship  called 
equipment-to-organization  relationships  (ETOR)  is  introduced  to  accompany  OTOR  and  PTOR. 
In  this  section,  the  term  “assignment”  is  used  for  OTORs  to  complement  the  term  alignment  for 


ETORs.  Thus,  the  associations  between  organizations,  people,  and  equipment  can  now  be 
unambiguously  defined. 

There  is  a  famous  saying  that  “the  Air  Force  and  Navy  man  equipment,  while  the  Army  and 
Marines  equip  the  man.”  Although  this  is  an  obvious  exaggeration,  it  represents  two 
philosophical  differences  that  show  up  between  types  of  crews.  One  interpretation  is  that  the 
difference  between  habitual  and  non-habitual  relationships  is  what  is  actually  being  reflected. 
This  is  true  for  OTORs,  PTORs,  and  ETORs.  In  other  words,  a  relationship  between 
organizations,  a  person  and  a  billet,  or  an  asset  and  an  organization  can  have  a  default  mode  of 
either  habitual  or  non-habitual  and  this  has  a  dramatic  effect  on  the  perception  of  the 
organizational  structure5.  For  example,  some  may  prefer  the  word  “system,”  as  opposed  to  crew 
because  the  asset  is  the  focus  of  the  operational  task  at  hand.  This  is  perfectly  acceptable  as  long 
as  the  semantics  are  consistent.  There  is  nothing  special  about  crews  other  than  the  fact  that  they 
correspond  to  a  major  asset,  such  as  a  vehicle,  aircraft,  or  ship. 

PTORs  are  normally  habitual.  Typically,  a  person  is  assigned  to  a  billet  for  the  duration  of  a  tour 
of  duty.  However,  the  billets  that  make  up  a  crew  may  be  habitual  or  non-habitual  (represented 
via  OTORs).  The  same  is  true  for  ETORs  (alignments).  This  is  illustrated  in  Figure  7.  For 


Figure  7:  Example  of  Habitual  and  Non-Habitual  Relationships 

ground  and  naval  forces,  crews  assignments  and  alignments  are  typically  habitual.  The  same 
people  usually  work  together  and  operate  the  same  equipment  each  time.  Aviation  units,  on  the 
other  hand,  attempt  to  keep  crews  together,  but  this  is  by  operational  practice  rather  than  by 
organizational  structure.  Aviation  alignments  (ETORs)  are  non-habitual.  Aircraft  are  provided 


5  To  quote  a  corollary  of  Murphy’s  Law:  “Where  one  stands  on  an  issue  depends  on  where  one  sits.” 


based  on  maintenance  and  other  scheduling  criteria.  No  one  has  a  “personal”  aircraft.6  There  are 
many  interesting  ramifications  caused  by  habitual  versus  non-habitual  relationships.  However, 
because  the  habitual  case  is  more  constraining,  the  non-habitual  case  should  be  considered  the 
general  case,  and  not  vice  versa. 

3.2.1  Assignments,  OTORs,  and  Organization  Trees 

Habitual  crew  assignments  are  the  most  common  default  for  ground  and  naval  forces.  For 
example,  an  M1A1  tank  crew  is  composed  of  four  billets:  a  tank  commander,  a  gunner,  a  loader, 
and  a  driver.  The  four  people  assigned  to  these  billets  think  of  themselves  as  a  permanent  team. 
Unless  there  is  a  significant  anomaly,  they  train  and  fight  together.  When  they  “fall  out  for 
formation”  in  the  morning,  they  will  be  standing  next  to  each  other.  They  may  even  be 
roommates.  Habitual  crew  assignments  manifest  themselves  in  organization  trees  by  the  billets 
being  shown  under  the  crew  as  the  default  case  as  is  illustrated  in  Figure  8. 


Figure  8:  Habitual  Assignments  and  Alignments  Figure  9:  Non-Habitual  Relationships 


Although  habitual  crew  assignments  are  desirable,  they  are  not  always  practicable.  Aviation 
crews  (i.e.,  those  greater  than  one)  may  be  composed  “ad  hoc,”  based  upon  many  variables  (e.g., 
a  crewmember’s  need  for  training  hours).7  Although  an  attempt  is  made  to  keep  crews  together, 
this  is  not  reflected  on  the  organization  charts.  Instead,  crews  are  composed  before  each  mission, 
and  although  the  same  crew  may  frequently  fly  together,  this  is  not  reflected  in  the  default 
organization  tree  as  is  illustrated  in  Figure  9.  Under  this  process,  the  crewmember  billets  can  be 
considered  temporarily  “attached”  to  a  crew  (organization)  for  the  duration  of  the  mission,  after 
which  the  billets  return  to  their  default  (assigned)  organizations.  Also  notice  that  OTORs  (i.e., 
the  links)  can  be  named  (e.g.,  “pilot”  and  “copilot”).  This  is  especially  useful  for  recurring 
temporary  links.  An  excellent  example  is  found  in  Marine  Expeditionary  Units  (MEU),  where  the 
attached  OTORs  for  the  air,  ground,  and  support  elements  can  be  named  permanently  (e.g.,  the 

6  People  in  organizations  that  are  habitually  aligned  are  surprised  to  discover  that  the  fighter  pilot  of  an  aircraft  is 
rarely  the  person  whose  name  is  on  the  aircraft! 

7  An  extreme  example  is  airline  crews,  where  crew  composition  is  determined  according  to  seniority  and  many 
other  factors.  Therefore,  a  pilot,  copilot,  and  the  several  flight  attendants  may  meet  for  the  first  time  just 
minutes  before  a  flight. 


ACE,  GCE,  and  MSSG  links).  Neither  the  habitual  nor  non-habitual  approach  to  assignments  is 
right  or  wrong;  they  are  just  different.  The  important  point  to  remember  is  that  either  case  must 
be  equally  viable  within  a  data  model  of  organization  structure  and  the  user  must  be  free  to  mix 
and  match  in  any  way  deemed  necessary  to  properly  represent  its  structural  state. 

3.2.2  Alignments,  ETORs,  and  Organization  Trees 

The  most  notable  feature  of  a  crew  is  the  one-to-one  correspondence  with  a  major  asset.  This 
means  that  for  every  “crew-served”  piece  of  equipment,  there  is  a  corresponding  organization. 
For  example,  there  is  a  ship  hull  (a  piece  of  materiel)  called  “CVN-73.”  However,  there  is  also  a 
corresponding  organization  called  “Crew  of  the  USS  George  Washington”  (or  some  other  name 
of  choice)  that  is  composed  of  Departments,  Divisions,  Work  Centers,  billets,  and  other 
subordinate  organizations.  If  the  piece  of  equipment  named  CVN-73  suddenly  sank,  there  would 
still  be  a  crew  of  5,000+  people  “floating  in  the  water”  complete  with  a  hierarchical  chain  of 
command.  Thus,  one  should  not  confuse  a  piece  of  materiel  with  the  corresponding  organization. 
This  was  illustrated  in  Figure  7,  where  Node  D  is  the  corresponding  crew  organization  for  the 
various  examples  of  materiel.  As  mentioned  previously,  it  is  perfectly  acceptable  to  think  of  the 
corresponding  organization  as  a  “system”  rather  than  a  “crew.”  The  former  presents  an  asset 
perspective  while  the  latter  provides  a  personnel  perspective.  Either  is  equally  acceptable 
provided  that  the  rules  for  manipulating  the  organizations  remain  consistent. 

Alignments  (the  association  between  equipment  and  an  organization  described  via  ETORs)  can  be 
either  habitual  or  non-habitual.  Crews  with  habitual  alignments  always  use  the  same  asset  (this  is 
illustrated  in  Figure  8).  The  crews  think  of  the  asset  as  “theirs”  (e.g.,  “my  ship”  or  “my  tank”), 
and  they  are  normally  responsible  for  some  level  of  maintenance.  During  the  force  development 
process,  crew  design  is  normally  based  on  a  one-to-one  ratio  of  crews  to  assets.  Consequently, 
the  force  structure  that  is  deployed  “to  fight”  (i.e.,  is  task  organized)  looks  very  similar  to  the 
default  force  structure  seen  in  garrison.  This  is  because  there  is  a  consistent  match  between  the 
association  of  personnel  and  assets  with  the  hierarchical  organization  structure.  For  example,  an 
Army  Ml  tank  company  has  14  tanks;  therefore,  there  will  be  14  crews  built  into  the  force 
structure  of  the  company.  Whether  in  a  deployed  state  or  garrison,  pairs  of  crews  are  defined  as 
Sections,  pairs  of  Sections  are  defined  a  Platoons,  and  a  set  of  Platoons  (actually  three)  constitute 
the  Company.8  Although  the  Tank  Company  Commander  technically  “owns”  (i.e.,  has  ultimate 
pecuniary  responsibility  for)  all  the  vehicles,  they  are  parceled  out  on  a  semipermanent  basis  to  the 
leaders  of  each  crew. 

Non-habitual  alignment,  the  normal  default  for  aviation  organizations,  is  the  less  constrained, 
general  case.9  The  primary  reason  for  non-habitual  alignment  is  that  the  assets  (aircraft)  require 
intensive  maintenance  on  a  regular  basis;  therefore,  it  does  not  make  sense  to  associate  a 
particular  crew  with  a  particular  piece  of  equipment.  Due  to  the  complexity  of  the  maintenance, 
non-habitual  crews  rarely  do  basic  maintenance  and  a  full  (often  larger)  maintenance  organization 
accompanies  the  sets  of  crews.  During  the  force  development  process,  the  organizational  design 
is  normally  based  on  a  higher  crew-to-asset  ratio  (e.g.,  1.5  crew  per  asset)  because  the  assets  are 


The  other  pair  of  tank  crews  operates  as  a  Section  in  the  Company  Headquarters. 
9  Force  developers  not  familiar  with  non-habitual  alignments  often  miss  this  fact. 


(1)  limited  in  number  due  to  their  cost,  and  (2)  are  complex  to  operate  and  require  crew  rest 
between  missions.10 

One  consequence  of  a  non-habitual  alignment  is  a  large  difference  between  the  default  and 
deployed  (i.e.,  task  organized)  organization  structure.  Since  crews  are  not  habitually  aligned  with 
an  asset,  the  primary  problem  becomes  how  to  represent  the  assets  organizationally  when  a  flight 
crew  is  not  using  them.  There  are  many  ways  to  do  this,  and  two  extreme  approaches  will  be 
discussed.  The  first  approach  is  to  think  of  the  organization  as  a  placeholder  for  the  asset.  This  is 
the  “system”  perspective  (referred  to  previously)  that  focuses  on  the  asset  rather  than  the  crew;  in 
other  words,  one  thinks  of  the  problem  as  “aligning  people  to  assets”  rather  than  “aligning  assets 
to  people” — either  approach  is  equally  valid.  For  example,  each  Air  Force  squadron  has  a  number 
of  Prescribe  Authorized  Aircraft  (PAA)  that  defines  the  number  of  aircraft  allocated  to  the 
squadron.  Under  this  approach,  illustrated  in  Figure  10,  there  would  be  one  “system”  (or  “crew”) 


Figure  10:  System  Oriented  Approach  To  Non-Habitual  Alignments 

organization  for  each  PAA.  If  the  PAA  were  six,  then  there  would  be  six  system  organizations 
called  “PAA-1”  through  “PAA-6”  (for  example).  To  each  of  these  positions  there  would  be  an 
aircraft  (a  piece  of  materiel)  aligned  under  some  ETOR.  The  default  structure  might  place  the 
“PAA”  organizations  directly  under  the  squadron  root  node  because  the  commander  is  ultimately 
responsible  for  all  the  aircraft.  When  the  time  comes  to  fly  a  mission,  a  crew  is  composed  by 
attaching  billets  that  reside  under  the  operational  flights  (i.e.,  A,  B,  and  C)  to  the  PAA  nodes. 

At  the  other  extreme,  one  may  envision  asset  alignment  as  establishing  a  temporary  ETOR  to  the 
organization  that  has  current  responsibility  for  the  asset.  Figure  11  illustrates  a  hypothetical 
structure  using  an  Air  Force  Fighter  Squadron.  In  this  example,  there  are  two  categories  of 
crews:  flight  crews  and  maintenance  crews.  Flight  crew  organizations  reside  under  the  set  of 
operations  flights  while  maintenance  crew  organizations  reside  under  the  set  of  maintenance 


10 


An  interesting  adjunct  to  this  is  ballistic  missile  submarine  crews,  which  are  habitually  aligned  but  have  a  ratio 
of  two  crews  per  asset  to  allow  maximum  use  of  the  assets  (i.e.,  a  “blue”  crew  and  a  “gold”  crew  per 
submarine). 
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Figure  1 1 :  Crew  Oriented  Approach  to  Non-Habitual  Alignments 


flights.  Although,  like  the  other  services,  the  commander  actually  “owns”  all  the  assets,  one  can 
think  in  terms  of  passing  “sub-hand-receipts”  from  the  commander  to  the  two  crews  as  each  takes 
responsibility  for  the  asset.  Initially,  the  aircraft  is  “given”  to  a  maintenance  organization  that 
takes  responsibility  for  it  while  it  is  not  involved  in  flight  operations.  When  the  time  comes  for  a 
mission,  responsibility  for  the  aircraft  is  transferred  to  the  crew  executing  the  mission  (led  by  the 
aircraft  commander).11  When  the  mission  is  completed,  responsibility  is  returned  back  to  the 
maintenance  crew  (led  by  a  “Crew  Chief’)-  This  cycle  continues  regardless  of  where  the  asset  is 
located.  The  asset  is  always  aligned  to  the  organization  responsible  for  it.12 


Notice  the  difference  between  the  two  approaches.  In  the  first  approach,  called  the  system 
approach,  the  alignment  between  the  aircraft  and  an  organization  (“system”)  is  fixed  and 
crewmembers  are  attached  to  the  system  (organization)  as  required.  In  the  second  approach, 
called  the  crew  approach,  asset  alignment  is  moved  between  organizations  based  on  which  one 
has  responsibility  for  the  asset.  Either  approach  is  viable,  as  well  as  any  mixture  of  the  two 
extremes.  However,  in  the  next  section  (on  Doctrinal  Organizations),  advantages  of  the  second 
approach  are  explained. 


1 1  Note  that  crews,  like  any  other  organization,  may  have  several  levels  of  subordinate  organizations  below  them 
(e.g.,  a  ship’s  crew),  and  ultimately,  those  subordinates  will  be  billets.  Figure  11  illustrates  an  extreme  case,  an 
Air  Force  Fighter  Squadron,  in  which  the  asset  requires  only  a  single  crewmember  (i.e.,  only  one  billet  per 
crew). 

12  Although  this  example  has  both  crews  within  the  same  squadron,  this  is  not  the  case  with  larger  aircraft,  such 
as  AW  ACS,  where  separate  squadrons  (e.g..  Aircraft  Generation  Squadron)  have  responsibility  for 
maintenance. 


3.3  Doctrinal  Organization 

Many  of  the  organizations  used  routinely  in  military  operations  do  not  show  up  in  manning 
documents;  these  types  of  organizations  have  been  coined  “Doctrinal  Organizations.”13  Most 
doctrinal  organizations  are  in  the  bottom  three  levels  of  the  organization  hierarchy  (the  bottom 
level  being  the  billet).  They  are  usually  based  upon  operational  heuristics  and  span  both  default 
and  operational  (i.e.,  task  organized)  organizational  structures.  For  example,  the  heuristic 
“always  try  to  fight  in  pairs”  is  almost  universal,  yet,  in  official  organization  charts,  one  rarely 
finds  the  organizations  that  are  routinely  used  as  a  result  of  this  rule.  From  this  basic  heuristic, 
the  concept  of  “lead”  and  “wingman”  appear  in  every  Service's  jargon  as  do  “section,”  “element,” 
or  “team.”  In  the  Army,  Navy,  and  Marines,  a  pair  of  assets  is  often  termed  a  “section,”  and  in 
the  Air  Force  it  is  called  an  “element.”  Yet,  one  will  rarely  find  these  organizations  listed  in  any 
official  manning  document  (e.g.,  see  footnote  3).  Within  a  manning  document,  doctrinal 
organizations  may  be  inferred  and  a  knowledgeable  person  may  be  able  to  extract  the  structure 
from  information  such  as  billet  titles.  But  in  practice,  doctrinal  organizations  are  found  explicitly 
only  in  Field  Manuals  and  other  documents  that  discuss  tactics  and  operational  procedures. 
Figure  12  illustrates  this  situation  for  a  U.S.  Army  Mechanized  Infantry  Platoon  (note:  the  leaves 
of  the  trees  are  billets  and  the  four  “M2  Crews”  are  each  aligned  with  a  Bradley  Infantry  Fighting 
Vehicle). 

The  importance  of  doctrinal  organizations  cannot  be  over  emphasized  because  without  them,  a 
primary  advantage  of  this  process  is  not  realized.  As  previously  stated,  one  of  the  basic 
hypotheses  presented  in  Chamberlain  [1998]  is  that  new  organizations  are  not  created  when 
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Figure  12:  Doctrinal  Organizations  Missing  From  Manning  Documents 


13  By  MAJ  Mike  Boiler,  of  the  U.S.  Army  TPIO-ABCS,  thus  replacing  other,  less  descriptive  terminology. 

14  Information  from  FM  7-7 J,  Mechanized  Infantry  Platoon  and  Squad  (Bradley),  Dated  7  May  1993  and  TO&E 
07247F000,  RFL  CO  INF  BN  (MECH)  (XXI),  Dated  23  Apr  1998. 


building  most  operational  chains  of  command.  Instead,  task  organizing  simply  requires  the  re¬ 
linking  of  existing  organizations.  This  is  illustrated  in  Figure  13.  The  top  two  boxes  in  Figure  13 
shows  two  “pure”  Army  companies:  one  tank  and  one  mechanized  infantry.  However,  it  is  often 
advantageous  to  mix  the  assets  of  the  two  organizations  to  provide  a  more  robust  and  effective 
fighting  team.  In  this  case,  the  two  companies  “swap”  one  of  their  platoons  for  one  from  the 
other.  From  a  data  abstraction  perspective,  what  has  occurred  is  that  two  new  OTORs  have  been 
temporarily  added  to  a  data  table:  one  for  each  swapped  (i.e.,  attached)  platoon  that  explicitly 
represents  that  from  Time  X  to  Time  Y  each  of  the  swapped  platoons  has  a  new,  temporary 
parent  organization.  Note  that  their  default  (assigned)  parent  relationships  never  change.  Rather, 
a  new  temporary  relationship  has  superseded  them.  In  Figure  13,  this  new  relationship  is 
illustrated  via  a  dashed  line. 


In  this  example,  no  new  organizations  (i.e.,  nodes  in  an  organization  tree)  were  created.  In  other 
words,  no  new  Org-IDs  were  created.  What  did  occur  was  the  creation  of  two  temporary  links 
(i.e.,  edges)  between  some  nodes  in  the  graph.  When  this  occurs,  doctrine  refers  to  the 
companies  as  “teams,”  and  they  are  often  provided  a  temporary  alias  (e.g.,  “Team  Alpha”  and 
“Team  Bravo”).  Further,  their  military  symbol  is  altered  by  adding  a  “hat”  to  the  company’s 
echelon  indicator  to  reflect  this  temporary  arrangement  in  organizational  structure.  Eventually, 
these  links  will  expire  and  the  graph  will  return  to  its  original  (default)  condition. 


Since,  from  a  graph  theory  perspective,  no  new  nodes  have  been  created,  it  is  argued  that  no  new 
organizations  have  been  created;  instead,  the  chains  of  command  have  been  augmented.  The 
beauty  of  this  approach  is  that  it  means  that  a  stable  set  of  organizations  can  be  created  ahead  of 
time  to  be  re-linked  at  a  later  time  at  the  discretion  of  the  command.  In  other  words,  although  the 
links  between  nodes  (OTORs),  people  and  nodes  (PTORs),  or  equipment  and  nodes  (ETORs)  are 
constantly  being  augmented,  the  identification  of  the  node,  the  ORG-ID,  is  a  stable  entity.  This 
has  dramatic  consequences  because  the  organization  database  entity  becomes  the  stable  rallying 
point  by  which  all  other  dynamic  attributes  are  tracked.  For  example,  as  a  result  of  the  simple 
task  organization  illustrated  in  Figure  13,  the  networked  computing  equipment  of  the 
organizations  involved  may  require  new  network  addresses  and  additions/subtractions  from 
associated  routing  tables.  All  of  this  can  be  automatically  reconfigured  because  the  equipment, 
personnel,  and  communication  channels  are  all  related  via  the  central  concept  of  the  organization 
(identified  via  Org-IDs).  Thus,  the  formal  organization  structure  provides  the  enabling  core 
information  that  is  prerequisite  for  building  truly  adaptive  and  self-configuring  systems. 

However,  for  this  approach  to  work,  the  correct  organizations  must  be  available  to  which  to 
temporarily  attach,  and  most  of  these  organizations  are  doctrinal  organizations.  If  they  don't 
exist,  new  nodes  must  be  created,  and  this  would  cause  a  huge  burden  on  the  command, 
administrative  and  communication  systems  of  the  organization.  Thus,  it  is  imperative  that  the 
time  and  expertise  be  committed  to  insert  explicit  doctrinal  organizations  into  manning  documents 
and  the  force  development  process.  The  aversion  is  that  adding  doctrinal  organizations  to  current 
manning  documents  is  a  time-consuming  and  intellectually  taxing  activity  that  must  be  done  by 
domain  experts  that  have  a  rigorous  understanding  of  military  operations.  But  the  pay-off  is 
large. 

3.4  Putting  The  Pieces  Together 

When  all  the  pieces  are  combined,  one  has  (by  definition)  a  Default  Operational  Organization.  In 
other  words: 

Default  Operational  Organization  (DOO)  = 


Administrative  Organization 

(a) 

(e.g.,  TO&E,  UMD,  TO/TE,  SMD) 

+ 

Doctrinal  Organizations 

(b) 

+ 

Crews 

(c) 

+ 

Billets 

(d) 

+ 

Administrative  Organization  “Fixes” 

(e) 

(e.g..  Command  Structure) 

This  is  the  organizational  structure  that  is  maintained  in  org  servers  to  be  shared  (to  the  extent 
desired)  within  the  Service  and  between  joint  and  coalition  partners.  By  including  these 
organizational  building  blocks  into  one,  homogeneous  structure,  an  immensely  flexible  capability 
that  allows  commanders  to  construct  any  imaginable  task  organization  with  widely  shared, 
predefined  entities  is  provided. 


A  simplified  example  is  illustrated  in  Figure  14  for  an  Air  Force  Strike  Package.  In  this  scheme, 
doctrinal  organizations  called  “Elements”  are  inserted  under  the  flights.  Since  deployment  in  pairs 
(or  larger  groups)  of  assets  is  desirable,  one  element  is  introduced  for  every  two  assets  in  the 
squadron’s  PAA.  Using  the  crew  approach  (versus  the  system  approach),  each  element  has  two 
crew  organizations  subordinate  to  it.  Assets  will  be  aligned  with  these  (crew)  organizations. 
Under  the  crew  echelon  resides  the  crew  billets,  thus  completing  the  organization  tree  down  to 
the  individual  level  within  the  Default  Operational  Organization.  Since  this  example  is  an  F-16 
Fighter  Squadron,  there  is  only  one  billet  per  crew  (note:  only  one  of  the  six  billets  is  shown  in 
Figure  14,  and  none  of  the  people  assigned  to  the  billets  is  shown  in  the  DOO).  In  this  special 
case,  there  is  a  temptation  to  dismiss  one  of  the  two  entities  (crew  or  billet)  as  redundant,  but  this 
would  deviate  from  the  general  nature  of  the  problem.  If  application  software  expects  billets 
under  crews,  then  deleting  crews  (for  example)  could  introduce  anomalies.  Finally,  people  (e.g., 
pilots)  are  assigned  to  the  billets  (via  PTORs).  It  is  assumed  in  this  example  that  the  aircraft  are 
aligned  (via  ETORs)  with  maintenance  crews  until  the  flight  crews  (i.e.,  pilots)  need  them. 

When  a  mission  is  announced,  a  strike  package  can  be  constructed  using  only  these  predefined 
organizations;  no  new  organizations  need  to  be  created.  Conceptually,  any  combination  of 
organizations  may  be  temporary  re-linked,  although  most  are  not  tactically  sensible.  First,  one  of 
the  element  organizations  of  the  squadron  is  selected  to  serve  as  the  “Strike  Package”  root 
organization;  in  this  case,  it  is  Element  B,  and  it  is  given  the  temporary  alias  “Package  53.” 
Element  B  is  chosen  because  one  of  its  subordinate  billets  corresponds  to  the  person  selected  to 
be  the  Strike  Package  Leader  (i.e.,  the  pilot  with  nickname/call-sign  “Spam”).  This  command 
relationship  is  easily  inferred  by  using  two  links.  The  first  command  link  already  exists  because, 
this  organization  having  single  crewmember  aircraft,  every  pilot  billet  automatically  “commands” 


Figure  14:  Building  a  Simple  Strike  Package 


the  crew  of  which  it  is  a  part.  However,  a  new  OTOR  that  explicitly  identifies  Crew-3  as  being 
the  commander  of  the  strike  package  must  be  temporarily  added.  Therefore, 

IF  P  is-commander-of  Crew-3  AND  Spam  is-assigned-to  P  AND 
Crew  3  is-commander-of  Element  B . 

THEN  Spam  commands  Element  B,  which  has  the  temporarily  alias  of  Package  53. 

Second,  one  crew  (from  Flight  B)  per  desired  aircraft  is  attached  to  the  strike  package 
organization.  Since  crews  3  and  4  are  already  assigned  to  Element  B,  they  are  already  included 
under  the  package.  However,  crews  5  and  6  from  Element  C  are  attached  to  the  package  via  a 
separate  OTOR.  The  crews  can  also  be  given  aliases;  in  this  case,  they  are  “renumbered”  1 
through  4 — or  realistically,  “Spam-1”  through  “Spam-4.” 


Finally,  aircraft  are  aligned  to  fill  the  package  with  the  required  assets.  In  this  case,  aircraft 
(materiel)  with  tail  numbers  are  aligned  with  the  crews  of  package  53.  Previously  in  this  paper,  it 
has  been  stated  that  the  concept  of  organization  serves  as  the  rallying  point  for  which  all  other 
battlefield  entities  relate.  This  means  that  the  location  of  the  crew,  which  corresponds  to  the 
location  of  the  aircraft,  is  maintained  and  exchanged  as  organizational  information.  If  the  aircraft 
has  an  onboard  guidance  system,  then  the  location  data  are  maintained  as  organizational  attributes 
in  the  tables  (or  objects)  of  the  database.  The  average  location  of  all  four  aircraft  (i.e.,  crews)  can 
be  maintained  under  the  Element  B  (currently  named  Package  53)  entry  in  the  organization  table. 
Should  package  53  need  to  split  into  two  groups,  as  illustrated  in  Figure  15,  this  is  a  simple  task. 
First,  another  (unused)  element  of  the  flight  is  selected  and  given  an  alias.  Then,  two  of  the  four 
crews  are  attached  to  the  new  element,  and  a  commander  is  identified  and  explicitly  annotated  as 


Figure  15:  Strike  Package  Split  During  Operations 


per  the  previous  example.  Merging  the  strike  package  back  together  is  accomplished  by  reversing 
this  process. 


It  should  be  clear  that  this  task  organization  process  is  equally  applicable  to  large  organizations, 
such  as  a  Carrier  Battle  Group  or  a  Marine  Expeditionary  Unit,  as  it  is  to  small  unit  operations. 
The  goal  is  to  design  a  set  of  data  abstractions  and  processing  that  are  completely  general  in 
nature  and  homogeneous  so  that  they  can  be  applied  seamlessly  to  any  task  organization  problem. 
Flexibility  is  another  feature  of  a  general  approach.  For  example,  any  organization  that  is 
routinely  used  may  be  added  as  a  doctrinal  organization.  It  doesn’t  matter  if  it  is  often  “empty” 
(i.e.,  it  doesn’t  have  any  permanently  assigned  subordinate  organizations).  Command  Posts  and 
watches  are  good  examples  of  these  cases. 

It  is  also  noted  that  these  examples  demonstrate  details  that  would  normally  not  be  viewed  by  the 
operators  of  such  a  system.  The  user  interface  should  be  design  to  be  familiar  to  the  operator. 
The  warrior  should  be  able  to  be  completely  ignorant  of  the  organizational  semantics  presented. 
Eventually,  a  common  application  could  be  developed  for  accomplishing  task  organization 
construction  that  is  “standard  issue”  for  any  battle  command  system. 

4.  Summary 

This  paper  introduces  a  technique  for  representing  military  organizational  information  called 
Default  Operational  Organizations  (DOO).  DOOs  are  graphical  tree  structures  that  provide 
enough  detail  to  meet  the  requirements  necessary  to  build  arbitrary  Orders  of  Battle  across  service 
and  coalition  boundaries.  By  closely  studying  how  each  Service  organizes  for  combat,  basic 
tenets  were  developed  in  an  attempt  to  reduce  many  apparently  (but  not  actually)  disparate 
practices  to  a  few  fundamental  concepts.  The  result  is  a  set  of  guidelines  based  upon  the  "best 
practices"  of  all  the  services. 

Three  types  of  organizations  were  explicitly  defined:  (1)  billets  that  correspond  one-to-one  with 
people,  (2)  crews  that  correspond  one-to-one  with  major  assets  (i.e.,  materiel),  and  (3)  doctrinal 
organizations  that  represent  organizations  that  are  routinely  used  in  military  operations  but  are 
rarely  included  in  manning  documents.  Once  the  concept  of  organization  is  extended  down  to  the 
billet  level,  crews  are  identified,  and  doctrinal  organizations  are  added,  the  result  is  the  default 
operational  organization.  Each  organization  (or  node)  of  the  DOO  tree  graph  is  assigned  a 
worldwide  unique  organization  identifier,  or  Org-ID.  The  DOO  is  a  relatively  stable  structure 
that  typically  changes  only  over  periods  of  months  (i.e.,  when  force  structures  are  updated). 
Consequently,  the  data  can  be  batch  distributed  ahead  of  time,  as  needed,  to  field  commanders. 
From  the  default  operational  organization,  a  myriad  of  task  organizations  can  be  built,  at  any 
echelon,  without  creating  any  new  organizations.  Instead,  existing  organizations  are  temporarily 
re-linked  (using  their  Org-Ids)  and,  often,  are  given  a  temporary  alias.  Examples  are  numerous: 
an  Army  Battalion  Task  Force,  a  Navy  Carrier  Battle  Group,  a  Marine  Expeditionary  Unit,  and  a 
Joint  Task  Force  or  Joint  Strike  Package.  All  of  these  operational  organizations  can  be  created  by 
re-linking  existing  organizations.  The  re-linking  data  are  terse  and  can  be  disseminated  via  digital 
versions  of  the  field  order  or  plan  (e.g.,  Operations  Orders  and  Air  Tasking  Orders). 

The  DOO  also  serves  as  the  skeleton  by  which  other  entities  can  be  related.  Three  type  of 
relationships  were  introduced:  OTORs,  or  Organization-to-Organization  Relationships,  to  define 


associations  between  organizations  (i.e.,  for  task  organizing);  ETORs,  or  Equipment-to- 
Organization  Relationships,  to  define  associations  between  materiel  and  organizations  (called 
alignments),  and  PTORs,  or  Personnel-to-Organization  Relationships,  to  define  associations 
between  people  and  organizations — in  particular,  billets.  Therefore,  OTORs,  ETORs,  and 
PTORs  can  be  used  to  pull  together  operational  databases  with  those  for  personnel  and  logistics. 
This  is  because  the  concept  of  task  organization  serves  as  the  foundation  for  these  other  battle 
command  entities. 

Task  organization  is  at  the  heart  of  the  Military  Capability  Package  (MCP)  process.  The  vision  is 
that  each  Service  will  maintain  an  “org  server”  that  contains  its  default  operational  organization  in 
a  common  form  that  is  readily  accessible  by  the  others  services.  The  Army  is  currently  pursuing 
this  for  Force  XXI,  and  the  DOO  concept  is  fully  extensible  to  coalition  forces.  Finally,  a 
common  application  (e.g.,  a  “Joint  Task  Organization  Toolkit”)  could  be  developed  to  allow  rapid 
“plug-and-play”  of  organizations  across  Service  and  coalition  boundaries.  This  application  would 
be  a  piece  of  “standard  issue”  software  for  battle  command  systems. 

5.  References 

[Chamberlain,  1998]  Sam  Chamberlain.  Technical  Foundations  for  Emerging  Battlefield 
Information  Management.  Proceedings  of  the  1998  Command  and  Control  Research  and 
Technology  Symposium.  Naval  Postgraduate  School,  Monterey,  CA,  29  Jun  -  1  Jul  1998. 

Acknowledgments 

The  following  organizations  and  people  contributed  operational  advice  to  this  research  effort: 

•  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  Program  Information  Office  (TPIO) 
for  Army  Battle  Command  Systems  (ABCS),  Fort  Leavenworth,  KS.  In  particular,  COL 
James  Bessler,  LTC  Robert  Hartel,  and  MAJ  Mike  Boiler,  and  MAJ  Robert  Savage  (USMC). 

•  The  U.S.  Air  Force  C4ISR  Center,  Langley  AFB,  VA.  In  particular,  Mr.  Garry  Barringer  and 
MAJ  Bryan  Bearden. 

•  The  U.S.  Navy  N3,  the  Pentagon.  In  particular,  LCDR  Patrick  Dunn. 

•  The  U.S.  Naval  Warfare  Development  Center,  Newport,  RI.  In  particular,  CDR  Craig  Geron 
and  LCDR  Estes. 


